SYSTEM AND METHOD FOR MANAGING ACCOUNTS PAYABLE 



5 RELATED APPLICATIONS 

This application claims the benefit of U.S.Provisional Patent Application Serial 
No. 60/465,977 filed April 28, 2003 which application is incorporated herein by 
reference in its entirety. 

10 BACKGROUND 

The subject invention relates generally to a system and method for managing 
accounts payable. 

As described in U.S. Patent No. 6,044,362, invoicing and payment collection has 
always been a very labor intensive and paper intensive process. Typically the process has 

15 involved an invoicer, usually a business, who prepares an invoice detailing the goods and 
services provided and the charges therefor. The invoice is mailed to a customer who 
verifies the correctness of the invoice and returns a payment coupon of some type along 
with a paper check to the invoicer. The invoicer then submits the paper check to its bank 
for payment through, for example, the Automated Clearing House (ACH) network.. 

20 Other similar payment systems include writing a credit card number and endorsing and 
preauthorization to draft an account on a monthly basis up to preset limits, such as 
regularly paying utility bills from a checking account. 

To automate this process, attempts have been made to utilize the services of third 
parties that receive and transmit between the invoicer and the banks involved electronic 

25 information relating to payments due from a customer. Although these systems appear to 
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streamline the process, they, in fact, may add a great deal of complexity and no small 
amount of expense to the process. Such electronic systems are described in, for example, 
U.S. Patent No. 5,383,113; U.S. Patent No. 5,283,829; U.S. Patent No. 5,220,501; and 
U.S. Patent No. 5,465,206. 
5 Still further, U.S. Patent No. 6,044,362 describes an electronic invoicing and 

payment system for providing customers an opportunity to review and modify payment 
instructions carried out by the invoicer (i.e., a vendor of goods and/or services). The 
described system includes invoice presentment electronics having a control system and at 
least one remote authorization terminal having a customer interface. The control system 

10 of the invoice presentment electronics is adapted to provide billing data to the remote 

authorization terminal whereby the customer interface may be used to provide a response 
indicating one of acceptance of the billing data for automated billing or modification of 
the billing data for modifying automated billing. 

While the aforementioned systems generally work for their intended purpose, they 

15 do, however, suffer the disadvantage that the systems are customer-centric, i.e., the 
customer is required to manage all information pertaining to the accounts payable 
process. It will also be appreciated that, in such systems, the vendor is placed at the 
disadvantage of not being able to gain access to information related to accounts payable, 
e.g., to view the status of outstanding invoices. Accordingly, a need exists for a system 

20 and method that will allow a vendor to have increased participation in the accounts 

payable process. More specifically, a need exists for a system and method that will allow 
a vendor access to their own accounts payable records with a customer, e.g., to view 
invoice status, to initiate payments for goods and/or services, etc. 
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SUMMARY 

To address this and other needs, described hereinafter is an improved system and 
method for managing accounts payable. In particular, the method may be implemented 
5 in a third party system that functions to allocate at least a portion of an invoiced dollar 
amount to a virtual account associated with a vendor (e.g., when an invoice including the 
invoiced dollar amount in approved by a customer), allow the vendor to request that a 
dispersal dollar amount be transferred from the virtual account to a real account 
associated with the vendor (e.g., by interacting with the system to write a virtual check), 

10 and initiate an electronic transfer of the dispersal dollar amount from a real account (e.g., 
one maintained by the third party but including funds deposited by the customer) to the 
real account associated with the vendor. 

A better understanding of the objects, advantages, features, properties and 
relationships of the subject system and method will be obtained from the following 

15 detailed description and accompanying drawings which set forth illustrative embodiments 
which are indicative of the various ways in which the principles of the system and 
method may be employed. 

BRIEF DESCRIPTION OF THE DRAWINGS 
20 For a better understanding of the system and method for managing service 

requests, reference may be had to preferred embodiments shown in the following 
drawings in which: 

Figure 1 illustrates a block diagram of an exemplary computer system in which 
the principles of the subject invention may be employed; 
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Figure 2 illustrates a flow chart diagram of an exemplary method for managing 
service requests; 

Figure 3 illustrates a process flow diagram of an exemplary method for managing 
service requests; 

5 Figure 4 illustrates a further process flow diagram of the exemplary method for 

managing service requests with a particular focus on the service requestor; 

Figure 5 illustrates a further process flow diagram of the exemplary method for 
managing service requests with a particular focus on the service provider; 

Figures 6-8 illustrate exemplary screen shots of Web pages by which a client 
1 0 service provider may register with the subject system; 

Figure 9 illustrates an exemplary screen shot of a Web page by which a service 
requestor may indicate a desire to have a service request fulfilled; 

Figure 10 illustrates an exemplary screen shot of a Web page for use in managing 
a service provider on-line office; 
15 Figure 1 1 illustrates an exemplary screen shot of a service provider rating; and 

Figure 12 illustrates an exemplary system and method for managing accounts 
payable. 

DETAILED DESCRIPTION 
20 Turning to the drawings, wherein like reference numerals refer to like elements, 

an exemplary system and method for managing accounts payable is illustrated and 
described. While described in the context of a system and method for managing service 
requests, it is to be appreciated that this context is not intended to be limiting. Rather, it 
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is contemplated that the system and method for managing accounts payable described 
hereinafter may be utilized in connection with any system and method that requires 
accounts payable management. Still further, the system and method will be described, by 
way of example only, in the general context of computer executable instructions being 
5 executed by one or more processing devices such as a personal computer, mainframe 
computer, personal-digital assistant ("PDA"), cellular telephone, or the like. Generally, 
the computer executable instructions reside in program modules which may include 
routines, programs, objects, components, data structures, etc. that perform particular tasks 
or implement particular abstract data types. In this regard, those skilled in the art will 
10 appreciate that the system and method described hereinafter may also be practiced in 
distributed computing environments where tasks are performed by various processing 
devices that are linked through a communication network and where program modules 
may be located in both local and remote memory storage devices associated with such 
processing devices. 

15 A network system in which the subject system and method may reside is 

illustrated by way of example in Fig. 1 . In the illustrated network system, a Command 
Center 20, illustrated in the exemplary form of a computer system, is provided to manage 
service requests in a manner that will be described in greater detail hereinafter. While 
described and illustrated as a single computer system, it is again emphasized that the 

20 Command Center 20 may be implemented such that tasks are performed by various 
processing devices that are linked through a communication network. 

For performing the various tasks, the Command Center 20 preferably includes a 
processing unit 22 and a system memory 24 which may be linked via a bus 26. Without 
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limitation, the bus 26 may be a memory bus, a peripheral bus, and/or a local bus using 
any of a variety of bus architectures. By way of further example, the bus 26 may include 
an architecture having a North Bridge and a South Bridge where the North Bridge acts as 
the connection point for the processing unit 22, memory 24, and the South Bridge. The 
5 North Bridge functions to route traffic from these interfaces, and arbitrates and controls 
access to the memory subsystem from the processing unit 22 and I/O devices. The South 
Bridge, in its simplest form, integrates various I/O controllers, provides interfaces to 
peripheral devices and buses, and transfers data to/from the North bridge through either a 
PCI bus connection in older designs, or a proprietary interconnect in newer chipsets. 

10 As needed for any particular purpose, the system memory 24 may include read 

only memory (ROM) 28 and/or random access memory (RAM) 30. Additional memory 
devices may also be made accessible to the Command Center 20 by means of, for 
example, a hard disk drive interface 32, a magnetic disk drive interface 34, and/or an 
optical disk drive interface 36. As will be understood, these devices, which would be 

15 linked to the system bus 26, respectively allow for reading from and writing to a hard 

disk 38, reading from or writing to a removable magnetic disk 40, and for reading from or 
writing to a removable optical disk 42, such as a CD/DVD ROM or other optical media. 
The drive interfaces and their associated computer-readable media allow for the 
nonvolatile storage of computer readable instructions, data structures, program modules 

20 and other data for the Command Center 20. Those skilled in the art will further 

appreciate that other types of computer readable media that can store data may be used 
for this same purpose. Examples of such media devices include, but are not limited to, 
magnetic cassettes, flash memory cards, digital videodisks, Bernoulli cartridges, random 
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access memories, nonodrives, memory sticks, and other read/write and/or read-only 
memories. 

A number of program modules may be stored in one or more of the 
memory/media devices. For example, a basic input/output system (BIOS) 44, containing 
5 the basic routines that help to transfer information between elements within the 

Command Center 20, such as during start-up, may be stored in ROM 24. Similarly, the 
RAM 30 and/or the hard drive 38 may be used to store computer executable instructions 
comprising an operating system 46, one or more applications programs 48, other program 
modules 50, and/or program data 52. 

1 0 A user may enter commands and information into the Command Center 20 

through input devices such as a keyboard 54 and/or a pointing device 56. While not 
illustrated, other input devices may include a microphone, a joystick, a game pad, a 
scanner, etc. These and other input devices would typically be connected to the 
processing unit 22 by means of an interface 58 which, in turn, would be coupled to the 

1 5 bus 26. Input devices may be connected to the processor 22 using interfaces such as, for 
example, a parallel port, game port, firewire, or a universal serial bus (USB). To view 
information from the Command Center 20, a monitor 60 or other type of display device 
may also be connected to the bus 26 via an interface, such as video adapter 62. In 
addition to the monitor 60, the Command Center 20 may also include other peripheral 

20 output devices, not shown, such as speakers and printers. 

For operating in a networked environment, the Command Center 20 utilizes 
logical connections to one or more remote processing devices, such as client computer 
64, technician computer 66, database computer 68, and/or financial institution computer 



70. In this regard, while the remote processing devices have been illustrated in the 
exemplary form of computers, it will be appreciated that the remote processing devices 
may be any type of device having processing capabilities and/or the ability to establish a 
communication link with the Command Center 20 such as, for example, a cellular 
5 telephone. Again, the illustrated processing devices need not be implemented as a single 
device but may be implemented in a manner such that the tasks performed by the various 
processing devices are distributed to a plurality of processing devices linked through a 
communication network Thus, the remote processing devices may include many or all 
of the elements described above relative to the Command Center 20 including the 

10 memory storage devices and a display device. The connection between the Command 
Center 20 and the remote processing devices is typically made through a further 
processing device 72 that is responsible for network routing. Furthermore, within such a 
networked environment, it will be appreciated that program modules depicted relative to 
the Command Center 20, or portions thereof, may be stored in the memory storage 

15 devices of the remote devices. It will also be understood that interface devices may also 
be used to establish links with devices lacking processing power, for example, an 
interactive voice response ("IVR") system may be used to allow a conventional telephone 
to be interfaced with the Command Center 20. 

To manage service requests, acts and symbolic representations of operations will 

20 be performed by the processing devices illustrated in Fig. 1 . As such, it will be 
understood that such acts and operations, which are at times referred to as being 
computer-executed, include the manipulation by the processing devices of electrical 
signals representing data in a structured form. This manipulation transforms the data or 



maintains it at locations in the memory system, which reconfigures or otherwise alters the 
operation of the processing devices 20, 64, 66, 68, and 70 in a manner well understood by 
those of skill in the art of computer systems. The data structures where data is 
maintained are physical locations of the memory that have particular properties defined 
5 by the format of the data. Nevertheless, while described in the foregoing context, this 
description is not meant to be limiting as those skilled in the art will further appreciate 
that various acts and operations described herein may also be implemented in hardware. 

By way of further example, the subject system and method may be implemented 
using a tiered architecture where one tier includes a front-end data base and Web 

10 applications running on Web server(s) that constitute an interface between users and the 
back-end of the system. In this manner, authorized users may access the system through 
a Web browser having a graphical user interface, for example, provided by a Java applet 
or as a common HTML page. To secure the system, the Web application may be 
surrounded by a firewall. The application logic would then constitute a further tier and 

15 may reside on a cluster of application servers including all of the capabilities necessary to 
support multiple transactions simultaneously. 

For use in controlling, building, and deploying a scalable workforce to solve 
service related problems, the Command Center 20 is used to provide an essentially 
automated system to link service requestors, e.g., corporate help-desk managers, with 

20 service providers, e.g., computer repair technicians. To this end, the Command Center 20 
operates to provide a networked supply chain management system by which a service 
requestor may choose one or more service providers, monitor the work performed by the 
service provider, and remit payment to the service provider(s) as generally illustrated in 
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Fig. 3. It is also contemplated that the operator of the Command Center 20 would 
receive a fee on each transaction from one or both of the service provider (e.g., a 
percentage of invoice amount based on volume of completed work orders per month) and 
the service requestor (e.g., a flat fee). It is also contemplated that the operator of the 
5 Command Center 20 may provide fee services to companies whereby the operator of the 
Command Center 20 essentially functions as a centralized help desk and arranges for 
service providers to meet the needs of service requestors. 

For a service requestor to become a client of the Command Center 20, the service 
requestor preferably registers with the Command Center 20, for example, by accessing a 

10 Web site maintained by the Command Center 20 using client computer 64 and by 
providing information requested by the Command Center 20. This information may 
include, but need not be limited to, preferred fees, geographic locations, preferred service 
providers, preferred hours of availability, preferred certifications, identification of 
employees that are authorized access, etc. As generally illustrated in Fig. 4, the operator 

15 of the Command Center 20 may also require service requestor clients to deposits funds 
into an account accessible by the Command Center 20 for reasons that are described in 
further detail hereinafter. Management of deposit account funds may be performed 
directly by the Command Center 20 or the Command Center 20 may interact with one or 
more financial institution computers 70 for this same purpose. Among other things, the 

20 registration of the service requestor as a client of the Command Center 20 addresses a 
need for companies to have a single point of contact and solves the problem of payments 
to, and management of, multiple vendors. Registration information may be stored and 
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accessed by the Command Center 20 directly or by means of cooperation with a database 
server computer 68. 

Once a service requestor client has registered with the Command Center 20, 
service requestor clients will be able to link to the Command Center 20 to perform tasks 
5 such as, for example, updating and/or changing registration information, forming a web 
page, generating a service request, precisely identifying computer service personnel that 
the service requestor client desires to meet their service request, managing and following 
up on service requests, paying the service providers (e.g., requesting a withdraw against 
their deposit), negotiating service contracts, and/or providing feedback on each service 

10 provider. In this regard, service requestor clients may access the Command Center 20 by 
means of the Internet, e.g., by accessing a Web site page maintained by the Command 
Center 20, and/or through the use of APIs that function to directly interface client 
computer 64 with the Command Center 20. 

For a service provider to become a client of the Command Center 20, the service 

15 provider also preferably registers with the Command Center 20, for example, by 

accessing a Web site maintained by the Command Center 20 using technician computer 
66 and by providing information requested by the Command Center 20, as generally 
illustrated in Fig. 5. In this regard, as illustrated by way of example in Figs. 6-8, the 
service provider may be requested to provide information to create an account with the 

20 Command Center 20 as well as information that will become available via an on-line 

office to potential service requestors. To these ends, the Command Center 20 may collect 
information concerning a client service provider company and/or information concerning 
individual employees of the client service provider. Thus, information collected during 
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the registration process may include contact information for the company and/or 
individuals, employee skill sets, geographical locations for service areas, availability 
times, rates, response times, certifications, languages spoken, etc., as is particularly 
illustrated in Figs. 6-8. Fig. 10 further illustrates a screen shot of an exemplary page 
5 whereby a service provider may manage their on-line office, e.g., to modify a company 
profile, add team members, change contact information, etc. In this manner, the system 
provides intuitive on-line tools for marketing each provider and managing workflow. 

As noted, once such registration information has been collected by the Command 
Center 20, a service provider client will have the equivalent of an on-line office with the 

10 Command Center 20 which is accessible by service requestor clients. The on-line office 
may also be made accessible to the general public. Access to the on-line office can be 
made directly via the Command Center 20 and/or by the service provider client causing 
URLs relating to the service provider client to be redirected to their on-line office as 
maintained by the Command Center 20. Again, the on-line office preferably contains 

15 information that would be viewable by potential service requestors such that a potential 
service requestor can discern if a particular client service provider is appropriate for a 
given service need. 

For requesting services, a client service requestor may contact the Command 
Center 20 to create a work order. In this regard, the Command Center 20 may be 
20 contacted via any means such as, for example, accessing the Command Center 20 Web 
site via a processing device (e.g., client computer 64) contacting Command Center 20 
personnel via telephone, PDA, facsimile machine, e-mail, paging network, radio 
telephone, or the like. In these latter instances, the Command Center 20 personnel may 
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be required to then manually enter the service request information into the Command 
Center 20 for the purpose of allowing the Command Center 20 to create a work order. An 
exemplary screen for creating a work order is illustrated by way of example in Fig. 9. 

In response to the creation of a work order, the Command Center 20 may cause a 
fee to be deducted from the account of the client service requestor, for example, as a pre- 
paid retainer or transaction service fee. The fee may be deducted immediately or at some 
future time, such as upon completion of the service request. At this time, the created 
work order may also be routed by the Command Center 20 to one or more client service 
providers. In this regard, a client service requestor may specify one or more intended 
recipients of the work order. To this end, client service requestors may be provided with 
the ability to search the existing database of client service providers. Alternatively, the 
Command Center 20 may identify one or more client service providers for the work order 
based upon information contained in the work order or otherwise specified by the client 
service requestor. Information utilized to route work orders in this manner may include a 
desired or required skill set, hourly rate, availability, geographic location, response time, 
range or experience, certifications, spend limit, and/or client service provider rating. It 
will also be appreciated that the information utilized to route work orders may be pre- 
established by a client service requestor, for example during the registration process, or it 
may be supplied in connection with the request for services. 

To direct work orders to intended recipients, the Command Center 20 may cause 
work orders to be transmitted to one or more of a technician computer 66, telephone, 
PDA, facsimile machine, e-mail account, pager, etc. of a client service provider. The 
recipient client service providers may then respond to the Command Center 20 to indicate 
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a desire to answer the service request. Preferably, the client service provider that is first 
to respond to the Command Center 20 and which is qualified to perform work associated 
with the service request is awarded the service request contract. Prior to and/or after the 
assigning of a service request, a client service requestor may access the Command Center 
5 20 to monitor all service logistics in real-time. For this purpose, any received service 
requests and/or work orders may be assigned a look-up number which would be 
transmitted to the service requestor. The service requestor may then indicate the look-up 
number to access status information maintained by the Command Center 20. 

When the service request that is the subject of the work order is completed by the 

10 client service provider, information concerning the completed service request is provided 
by the client service provider to the Command Center 20 using any of the communication 
methodologies described previously. The Command Center 20 may then issue a 
notification to the client service requestor which notification would contain information 
relevant to the completion of the service request/work order. Again, the service 

15 request/work order completion notification may be issued to the client service requestor 
by being transmitted to one or more of a client computer 64, telephone, PDA, facsimile 
machine, e-mail account, pager, etc. of the client service requestor. 

The client service requestor may transmit a response to the Command Center 20 
to confirm the completion of the service request and the satisfaction of the client service 

20 requestor with respect to the work performed. At this time, the client service requestor 
may also authorize the Command Center 20 to convert the work order to an invoice so as 
to allow the Command Center 20 to access the account of the client service requestor for 
the purpose of issuing payment to the client service provider. In this regard, payment 
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may be made electronically to an account of the client service provider, by issuance of a 
check, etc. A client service requestor may additionally access the Command Center 20 to 
complete a survey regarding the completion of the service request/work order by the 
client service provider. Information collected in such a survey may then be used to 
5 establish a rating for the client service provider for use in the future assignments of work 
orders, for example by providing an overall rating and ratings for one or more skill sets, 
punctuality, professionalism, etc. as illustrated in Fig. 11. 

In instances where the service provider is unable to complete the work order, for 
example, if a particular part must be replaced that needs to be specially ordered, the 

1 0 system may allow for the service provider to request that the work order be renegotiated 
with the service requestor for the purpose of addressing these additional needs. This 
negotiation may be done via message exchanges through the system or done directly 
between the parties. In either case, the system should be notified as to any changes or 
alterations to the work order so as to allow for the updating of the work order to ensure 

1 5 proper accounting. It is also contemplated that, in this case, the parties may agree that the 
work order is completed for purposes of accounting only and that the service requestor 
will issue a further service request for the purpose of having the repair work completed in 
actuality. 

From the foregoing, it will be appreciated that the subject system and method has, 
20 among others, the advantages of: providing corporate customers with a single point of 
contact, responsibility, and billing for offices throughout the country; allowing corporate 
customers to electronically control and monitor the service process; allowing corporate 
customers to choose service provider(s) in each region, by certifications (e.g., by Dell, 
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Compaq, Microsoft, etc.), by range of fees, by range of experience, etc. to insure proper 
and timely services throughout the United States; etc. The subject system and method 
also has the advantage of providing service requestors with a generic catalog of services, 
possibly at substantially reduced prices. Still further, the subject system and method may 
5 allow access to certain computer parts providers and or providers of additional services 
that may be required. 

With respect to the service providers, the subject system and method has, among 
others, the advantage of providing for a steady flow of work (i.e., in the form of work 
orders) whereby service provider personnel will be able to better manage their daily 

10 schedules, receive payments and earn more consistent pay while providing faster 
response times to end users. 

Still further, it is contemplated that service requestors and service providers may 
use information contained with the subject system to interact directly. Once service 
requestors and service providers are connected in this manner, the remaining 

15 functionality of this system may still be utilized so as to maintain centralized 
management of the service and/or payment processes. 

For managing the accounts payable process, a provider of services and/or goods 
(i.e., a vendor) is preferably provided with the ability to access accounts payable 
information, initiate payments, etc., as will be described in greater detail hereinafter. 

20 While the description of the accounts payable process will be in the context of the 
command center system described above, it is to be understood that the principles 
described hereinafter could also be performed through direct interactions between a 
requestor of services and/or goods and providers of services and/or goods. Accordingly, 
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the description that follows is intended to be illustrative only and is not intended to be 
otherwise read in a limiting manner. 

As illustrated in Fig. 12, a typical accounts payable process commences with the 
issuance of an invoice from the vendor. As will be appreciated, the invoice may be 
5 issued upon provision of requested services, shipment of goods, etc. Furthermore, as 
illustrated in Fig. 6, the invoice may be provided by the vendor electronically (e.g., via 
EDI, facsimile, email, etc.) or physically (e.g., via mail) without limitation. In this 
illustrated example, the invoice is provided to the operator of the command center 20 
whereupon it is entered into the command center system and, preferably stored within a 
10 database 68 of invoices so as to be cross-referenceable to both the service requestor and 
the service provider. Cross-reference may be by means of designators provided to the 
service requestor and the service provider during the registration process described 
above. 

In the example system, a received invoice is further preferably routed to the 
15 service requestor whereby the invoice may be approved. In this regard, the invoice may 
be routed to the service requestor generally and/or to one or more person(s) that have 
been designated as having invoice approval authority (e.g., management and/or 
accounting personnel). The intended recipients of invoices may be provided to the 
central controller system during the service requestor registration process. Preferably, the 
20 invoice is routed (to any one or more persons in the approval chain) using electronic 

means, such as email or the like. Furthermore, it may be desirable to track movement of 
the invoice whereby the tracking information may then be maintained within the database 
68 for ease in discerning the current location/present status of the invoice. 
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Once the invoice has been properly authorized for payment, the command center 
20 is preferably notified whereby the command center 20 may function to allocate the 
amount of the invoice to the vendor that issued the invoice. To this end, within the 
command center system, each customer and each vendor is preferably provided with a 
5 virtual account. Thus, when the invoice is approved, the command center 20 may 
function to debit the virtual account of the appropriate customer while crediting the 
virtual account of the appropriate vendor. As described previously, since the customer 
may be required to maintain and fund an account with the command center 20, the virtual 
account of the customer would preferably track the amounts within this funded account. 

10 Thus, if the virtual account of the customer is under- funded, the control center 20 may 
notify the customer of a need to increase their amount on deposit in order to meet the 
current payment requirement(s) and, possibly, for further work to be authorized on behalf 
of the customer. As a means for minimizing the likelihood of fraud, the system may only 
allow a predetermined amount of money to be transferred between virtual accounts over a 

15 predetermined period of time, e.g., a limit of $750.00 per day from a customer to a 
vendor. 

During this process, the vendor may be provided with an opportunity to access the 
records maintained within the command center 20 at their convenience to view 
information concerning the accounts payable process, e.g., to view invoice status, virtual 
20 account status, etc. In this manner, the vendor may quickly and easily discern where in 
the invoice approval process any invoice may be. Furthermore, once an invoice has been 
approved and funds allocated, the vendor may request that all or part of the allocated 
funds be transferred to a real account owned by the vendor. 
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To initiate the transfer of funds from the vendor virtual account to the vendor real 
account, the vendor may be provided with the ability to write themselves a virtual check 
against their virtual account. In this regard, all that may be required from the vendor is 
the amount that is to be paid from the virtual account. This amount may be limited to a 
5 predetermined amount of money over a predetermined period of time, e.g., the vendor 
may only be able to withdraw $750.00 per day from their virtual account. The remaining 
information needed for payment to the vendor may be supplied automatically by the 
centralized control system 20. For example, payee fields (e.g., company or individual 
name, payee account, etc.) may have been previously supplied to the centralized control 

10 system 20 at the time that the vendor registered with the centralized control system 20. 
In this manner, once the virtual check is prepared to the satisfaction of the vendor, the 
vendor may, for example, click on a "submit check" button or the like provided in a 
graphical user interface to initiate processing of the virtual check. Check records are 
preferably maintained within the database 68 so as to be accessible and viewable by a 

15 vendor - i.e., as a virtual check ledger. 

To process the virtual check, each submitted virtual check is preferably batched 
into a NACHA file and submitted to a financial institution associated with the ACH 
Network. Since a description of such an automated clearinghouse system may be found 
at, for example, "http://www.nacha.org/," a more detailed explanation will not be 

20 provided herein for the sake of brevity. Nevertheless, the submittal of the virtual check 
to the financial institution will result in the electronic transfer of funds from an account 
associated with the customer to the account designated by the vendor. In the illustrated 
case, the funds would be withdrawn from an account maintained by the operator of the 
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command center 20 in which deposits from customers are maintained. It will be 
appreciated that the electronic transfer of funds may also be accomplished in a similar 
manner by means of the vendor using a virtual credit card, pay pal, direct indication of a 
wireless account, etc. without limitation. Thus, it will be appreciated that the described 
5 system and method for managing accounts payable has, among others, the advantages of 
providing vendors with the ability to monitor their accounts and invoices and to ensure 
secure payment of vendor fees. 

It will also be appreciated that the principles of the described system may also be 
utilized to, for example, allow an operator of the command center 20 to initiate funding 

10 of a customer account. In such a case, the operator of the command center 20 may access 
a similar virtual check writing utility, which may have appropriate limits, to cause an 
electronic transfer of funds from a real account owned by the customer to the deposit 
account maintained by the operator of the command center. In the case of such electronic 
transfers, any amount transferred would be preferably reflected in the virtual account for 

1 5 that customer client. 

While various concepts have been described in detail, it will be appreciated by 
those skilled in the art that various modifications and alternatives to those concepts could 
be developed in light of the overall teachings of the disclosure. For example, it is 
contemplated that service requestors and service providers may useinformation contained 

20 with the subject system to interact directly. Once service requestors and service 

providers are connected in this manner, the remaining functionality of this system will 
still be utilized so as to maintain centralized management of the service and payment 
process. Furthermore, while described in the context of managing computer related 
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services, it will be appreciated that the concepts described herein may be used to manage 
provision of any type of services. By way of example only, the subject system and 
method may be used to manage the placement of temporary employees, to manage the 
placement of nurses, etc. where thework order would request the services of the 
5 temporary employee, nurse, (e.g., specifying a location, particular need, time, and the 
like) etc. As such, the particular concepts disclosed are meant to be illustrative only and 
not limiting as to the scope of the invention which is to be given the full breadth of the 
appended claims and any equivalents thereof. 



21 



